When organizations need to have large-scale computer systems that hold mission critical information, such as purchase orders, financial information, etc., they usually resort to message transaction systems. Message transaction systems ensure that data is not lost if the system crashes, and also that data is not duplicated—such as ensuring that two copies of the same purchase order are not processed, etc. A transaction is an activity or a request, such as an order, a purchase, a change, or an addition to a database of information. Transactions usually update one or more files on a non-volatile storage such as a hard disk drive, and thus can serve as both an audit trail and a history for future analyses. A transaction can include one or more messages. A transaction is considered committed when all the messages of the transaction have been received and processed.
For systems like message transaction systems, it is usually important that messages sent from a sender computer to a receiver computer are guaranteed to be delivered, and that they are delivered exactly once. For example, where a message relates to transfer money to a bank account, it is critical that the message is in fact delivered, so that trust can be placed in the system. Furthermore, it is critical that the message is delivered only once—so that the money is not transferred twice, etc. There can be pitfalls associated with guaranteed, exactly once delivery of messages. For example, the sender computer may crash, such that upon recovery it may not be known whether messages that were residing at the sender computer were sent or not.
Within the prior art, guaranteed exactly once delivery of messages is usually provided for by a transaction manager, or coordinator, within a transaction message system. The transaction manager is a bookkeeping program that keeps track of transactions, to ensure atomicity of transactions—that a given transaction completely executes or does not execute at all. Besides guaranteed exactly once delivery of messages, transaction managers also provide for in-order execution of transactional messages. This can result in significant processing overhead. Where only guaranteed exactly once message delivery is necessary—and not, for example, in-order execution of transactional messages—the performance penalty for using a transaction manager in such an instance can be prohibitive.
For these and other reasons, therefore, there is a need for the present invention.